Method and program for inhibiting attack upon a computer

ABSTRACT

A method ( 200 ) and program ( 100 ) for inhibiting attack upon a computer ( 120 ) is provided. The address ( 104 ) of a process ( 106 ) is produced ( 612 ), and encrypted ( 616 ) to produce an encrypted address ( 518 ), which is then stored in memory ( 128 ). When needed, the encrypted address ( 518 ) is retrieved ( 702 ) from memory ( 128 ) and decrypted ( 704 ) to reproduce the original process address ( 104 ). The reproduced process address ( 104 ) is then verified ( 708 ). If the process address ( 104 ) is determined ( 708 ) to be valid, i.e., there was no attack, then the process address ( 104 ) is placed ( 712 ) in the program counter ( 318 ), and a valid process ( 106 ) is executed. If the process address ( 104 ) is determined ( 708 ) to be invalid, i.e., there was an attack, then the address ( 108 ) of a crash and terminate process ( 110 ) is placed ( 716 ) in the program counter ( 318 ) and the computer ( 120 ) crashes. A nonce value ( 512 ) may be generated ( 602 ) and encrypted ( 616 ) and decrypted ( 704 ) in conjunction with the process address ( 104 ). The nonce value ( 512 ) may then be verified ( 710 ) independently, thereby increasing security.

RELATED INVENTION

[0001] The present invention claims benefit under 35 U.S.C. 119(e) to“Encryption-PC,” U.S. Provisional Patent Application Serial No.60/325,949, filed Sep. 28, 2001, which is incorporated by referenceherein.

TECHNICAL FIELD OF THE INVENTION

[0002] The present invention relates to the field of protectingcomputers against computer attacks. More specifically, the presentinvention relates to the field of code modification to inhibit computerattacks.

BACKGROUND OF THE INVENTION

[0003] Networked computers are highly vulnerable to a class of attacksknown as buffer overflow attacks. To exploit a buffer overflow, anattacker sends a message containing malicious code to a computer. Thismessage is crafted to override an address pointer with the address ofthe interjected malicious code. In due course, the overwritten pointeris copied into the program counter of the computer's central processingunit (CPU). The CPU then executes the malicious code.

[0004] Buffer overflow attacks can create a back door for the attacker,transfer sensitive information from the system, destabilize the system,or open the system to use as a source node in a distributed denial ofservice attack. Buffer overflow attacks are common, easy to exploit,hard to eliminate, and potentially highly damaging when successful.

[0005] Common implementations of the memory subsystem of many operatingsystems (e.g., Unix, Linux, and Windows 9x/me/2000/NT/XP) are vulnerableto exploitation by network-based attackers. The memory subsystem ofthese operating systems fails to provide adequate facilities to ensurethat unauthorized processes cannot access and alter memory.

[0006] One of the most common methods for attackers to gain unauthorizedaccess to networked hosts is to introduce malicious code throughexternally accessible network services (e.g., through the Internet or anintranet). The attacker typically sends a message containing themalicious code to a server process. The message is crafted to overwritea code pointer, causing the host CPU to jump to and execute theattacker's code. Since server processes typically operate with elevatedprivileges, the malicious code, when executed, usually has free rein onthe compromised system to access information or create a back door forthe attacker to access the machine at his convenience. Often, themalicious code will allow the use of the compromised system as a hostfor a secondary attack through the network. Many distributeddenial-of-service attacks have been launched from large numbers ofinnocent machines that had been compromised in just such a way.

[0007] These buffer overflow attacks are too easy to launch. Of theDepartment of Defense Computer Emergency Response Team (CERT) advisoriesthat describe attacks resulting in the attacker gaining elevatedprivileges on compromised systems, approximately 75% are buffer overflowattacks. Such attacks affect a wide range of server software running onan equally wide range of operating systems, both open source andcommercial. It is not just server software that is vulnerable. Clientsoftware has also been successfully subverted in a similar manner bycausing the processing of maliciously constructed web pages, mailmessages, and/or data files.

[0008] Although developing code for a buffer overflow attack may requirea certain amount of initial analysis and trial-and-errorexperimentation, once a suitable vulnerability has been uncovered in apiece of software, the means of exploiting it can easily be automated.Furthermore, the code developed is usually made freely available on theInternet. This makes the attack technique accessible to and usable byattackers with almost no technical sophistication.

[0009] Resistance to such attacks is desirable if an operating system isto be trusted. The traditional response to such an attack is reactive.That is, when vulnerability is discovered, the vulnerable software ispatched to eliminate the vulnerability. This is an after-the-factresponse, since vulnerabilities are often only discovered after a numberof attacks have been detected. Also, this response is slow, as patcheshave an appreciable lead-time in their development and dissemination.Additionally, this post-attack patching approach offers no protectionagainst vulnerable function calls that are not yet included.

[0010] Certain programming languages, most notably C and C++, areespecially vulnerable to buffer overflow attacks. This is because theselanguages pass pointers and function return addresses over the stack.Unix and Unix-like operating systems are typically written in C. Inthese operating systems, fixed code resides in a “text” segment, fixeddata resides in an “rodata” segment (which may be combined with the textsegment), variable code and data reside in a “data” segment, and i/obuffers and the stack reside in a “bss” segment. The text and rodatasegments are classed read-only. That is, the code and data contained inthese segments generally cannot be altered from the outside. The dataand bss segments, on the other hand, are classed as read/write. Code anddata in these segments are therefore vulnerable to attack.

[0011] In a typical buffer overflow attack, the attacker introduces codeinto the memory space of the target system, then the attacker causes theCPU to execute the code. The most common means of accomplishing this isby subverting one of the many “daemon” processes present in modernoperating systems. These are usually configured to both accept messagesfrom the network, and operate at high levels of privilege. To illustratea typical attack, consider a simplified example, where the daemon has asimple message-processing process that allocates one fixed-length bufferto store the incoming message. On entry, a stack frame contains abuffer/stack area in which the buffer grows upward and the stack growsdownward, i.e., the buffer and stack grow towards each other.

[0012] Normally, a message is received and placed in the buffer. Thismessage is then processed by a daemon whose return address is placed onthe stack. In this case, when the daemon terminates, the return addressis popped off the stack and loaded into the CPU program counter, andexecution continues as normal.

[0013] Now suppose an attacker wishes to compromise the host on whichthe daemon is running. The attacker constructs a message longer than thereserved space in the buffer, containing some code, additionalmeaningless data to fill the remainder of the memory space, and apointer to the code, designed to go exactly in the position of thereturn address.

[0014] The attacker has succeeded in “smashing the stack.” Now, when theprocess terminates, instead of the correct return address being poppedoff the stack into the program counter, the program counter is filledwith the address of the malicious code, which is duly executed, with thesame execution privileges as the subverted daemon process. This code canbe used to create a back door to allow the attacker to log in andperform other operations at his leisure.

[0015] Those skilled in the art will appreciate that there are manyvariations on this basic theme, not all of which involve overwriting thereturn address on the stack. Other code pointers may be overwritten,such as function pointers passed as parameters in C. These attacks haveone thing in common, however. They all rely on replacing a valid codepointer with a pointer to the attacker's code. The subverted pointer isthen loaded into the program counter in place of the legitimate pointerthat it replaces, and the malicious code is executed.

[0016] Stack-protection approaches have met with limited success. Theseapproaches attempt to prevent overwriting critical areas on the stackwhere code addresses might be found, or to detect such overwritingattempts. While effective on some buffer overflow attacks (untilattackers find a work-around, which they have often done), simplyprotecting the stack is an incomplete solution at best.

[0017] Conventional approaches overlook the fundamental problem. Anattacker can stage these attacks because the program counter can be madeto point to arbitrary locations. The conventional approaches fail toprotect the values loaded into the program counter.

SUMMARY OF THE INVENTION

[0018] Accordingly, it is an advantage of the present invention that amethod and program for inhibiting attack upon a computer is provided.

[0019] It is another advantage of the present invention that processaddresses are encrypted, stored, and decrypted prior to being placed inthe program counter.

[0020] It is another advantage of the present invention that encryptionand decryption of process addresses may be effected within a processor.

[0021] It is another advantage of the present invention that encryptionand decryption of process addresses is effected through the use of asecure key.

[0022] It is another advantage of the present invention that encryptionand decryption of process addresses may be effected in conjunction witha nonce value.

[0023] It is another advantage of the present invention thatpost-decryption verification of a process address is supported.

[0024] The above and other advantages of the present invention arecarried out in one form by a method for inhibiting attack upon acomputer. This method produces a process address to be used by a programcounter of the computer, encrypts the process address to produce anencrypted address, stores the encrypted address in a memory of thecomputer, retrieves the encrypted address from the memory, and decryptsthe encrypted address to reproduce the process address.

[0025] The above and other advantages of the present invention arecarried out in another form by a computer program configured to operateupon a computer and to inhibit attack upon the computer, wherein thecomputer program resides upon a computer-readable medium, and whereinthe computer program has a first code portion configured to encrypt aprocess address to produce an encrypted address, a second code portionconfigured to store the encrypted address in a memory of the computer, athird code portion configured to retrieve the encrypted address fromsaid memory, a fourth code portion configured to decrypt the encryptedaddress to reproduce the process address, and a fifth code portionconfigured to place the process address in a program counter of thecomputer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] A more complete understanding of the present invention may bederived by referring to the detailed description and claims whenconsidered in connection with the Figures, wherein like referencenumbers refer to similar items throughout the Figures, and:

[0027]FIG. 1 shows a schematic view depicting the relationship betweenan attack-inhibiting computer program and a computer in accordance withpreferred embodiments of the present invention;

[0028]FIG. 2 shows a flowchart depicting an attack-inhibiting procedureeffected by the computer program of FIG. 1 in accordance with preferredembodiments of the present invention;

[0029]FIG. 3 shows a schematic view depicting processors configured torun the computer program of FIG. 1 to execute the procedure of FIG. 2 inaccordance with preferred embodiments of the present invention;

[0030]FIG. 4 shows a flowchart of a key-generation sub-procedure of theprocedure of FIG. 2 in accordance with a preferred embodiment of thepresent invention;

[0031]FIG. 5 shows a bit-width comparison between addresses and valuesused in the computer program of FIG. 1 in accordance with a preferredembodiment of the present invention;

[0032]FIG. 6 shows a flowchart of an address-encryption sub-procedure ofthe procedure of FIG. 2 in accordance with a preferred embodiment of thepresent invention;

[0033]FIG. 7 shows a flowchart of an address-decryption sub-procedure ofthe procedure of FIG. 2 in accordance with a preferred embodiment of thepresent invention; and

[0034]FIG. 8 shows a flowchart of a compilation procedure for creationof the attack-inhibiting procedure of FIG. 2 in accordance with apreferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE-PREFERRED EMBODIMENTS

[0035] Throughout this discussion, items are assigned three-digitreference numbers whose first digit reflects the Figure in which theitem first appears. That is, items first appearing in FIG. 1 areassigned reference numbers between 100 and 199, etc. Once assigned, agiven reference number is used in all Figures in which that itemappears.

[0036] The present invention employs a general solution to provideprotection against buffer-overflow and other memory-manipulationattacks. This solution uses cryptography as a first-class operation.Specifically, pointers (addresses) to be used by the program counter ofa computer's central processing unit (CPU) are secured by encryption.Program-counter encryption defeats common forms of subversion of aprocess from within its own security perimeter.

[0037] The program counter is secured by encrypting addresses as theyare stored in memory, and decrypting those addresses as they are loadedinto the CPU program counter. Even if an attacker were able to insertmalicious code and overwrite an encrypted pointer, it would be nearlyimpossible for the attacker to compute the correct program counter valueto cause the CPU to execute the malicious code. At worst, a bufferoverflow could cause a daemon process to crash. This would typicallycreate a denial of service for the attacked computer, but this issignificantly more desirable than allowing the attacked computer to becompromised.

[0038] Advances in cryptographic algorithms and implementationtechniques have enabled the use of cryptography as a means forprotecting-memory on this large scale. The preferred embodiment of thepresent invention employs a type of cryptography defined by the AdvancedEncryption Standard (AES) algorithm from the National Institute ofStandards and Technology. The AES algorithm offers substantially higherperformance, simpler implementation, and higher security than previousalgorithms. In addition, the AES algorithm may be performed quickly. TheAES algorithm has been successfully applied to Internet protocolsecurity devices in networks operating at 10 Gb/s rates. This iscomparable to a typical 64-bit memory bus operating at 133 MHz. Inaddition, encryption latencies of around 20-30 ns for single 128-bit AESencryption operations are achievable in current application-specificintegrated-circuit technology. Such latencies are comparable to theexecution time of 10 instructions on high-end processors, and aresubstantially less than the access times of typical DRAM memories. Thisjump in cryptographic performance suggests that AES encryption anddecryption can be used as first-class operations, and exploited inworkstation hardware and software architectures.

[0039] Having an appropriately fast implementation is desirable for thepresent invention, but the answer is not as simple as inserting the AESalgorithm into an operating system kernel and memory bus. To secure theprogram counter, substantially all of the places where pointers are usedfrom the data space are identified, and consistently encrypted anddecrypted properly. These include pointers to functions, returnaddresses, dynamically linked libraries, etc. Substantially all of theplaces code is generated to use and store these pointers are alsoidentified, and a compiler is desirably modified to encrypt and decryptthe pointers during compilation. The major results of this task arekernel, compiler, linker, and loader modifications that substantiallythwart buffer overflow attacks by inhibiting the ability of an attackerto successfully overwrite pointers.

[0040] In the following discussion, processes and subprocesses within acomputer program serve to take an active role to inhibit attacks uponthe computer during initialization and execution of other processes,which other processes are the normal (i.e., non-attack-inhibiting)processes of the computer, including but not limited to, the operatingsystem and application programs of the computer. To avoid confusion, allprocesses and subprocesses involved in attack-inhibition are hereinafterreferred to as “procedures.”

[0041] In accordance with preferred embodiments of the presentinvention, FIG. 1 shows a schematic view depicting the relationshipbetween an attack-inhibiting computer program 100 and a computer 120.FIG. 2 shows a flowchart depicting an attack-inhibiting procedure 200,where procedure 200 is a process effected by computer program 100. FIG.3 shows a schematic view depicting processors 302 configured to runprogram 100 to execute procedure 200.

[0042] Program 100 is configured to run on computer 120 and executeattack-inhibiting procedure 200. As demonstrated in FIG. 1, however,program 100 itself resides upon a computer readable medium 122. Medium122 may be a transport medium 124, a system medium 126, a system memory128, CPU microcode 130, or hardware logic.

[0043] For purposes of this discussion, transport medium 124 is assumedto be a medium 122 (such as an optical or magnetic disc) external tocomputer 120, used to transport program 100, and/or from which program100 may be copied or loaded into computer 120. Similarly, system medium126 is assumed to be a medium 122 (such as a hard drive) within computer120.

[0044] While residing upon either transport medium 124 or system medium126, program 100 is dormant, i.e., inoperative. Typically, program 100is moved from transport medium 124 or system medium 124 to system memory128. Once in memory 128, program 100 may be executed to effectattack-inhibiting procedure 200.

[0045] The use of transport medium 124, system medium 126, and memory128 to contain program 100 is typical of a “software” embodiment of thepresent invention. In this case, program 100 is incorporated into anoperating system 304 of computer 120.

[0046] Alternatively, program 100 may be incorporated into CPU microcode130 within a CPU (central processing unit) 306 of computer 120, or maybe implemented directly in hardware logic as a “state machine” in CPU306. Discussions of microcode 130 hereinafter are assumed to pertainalso to state machines.

[0047] By being within CPU 306, program 100 operates invisibly withregard to operating system 304 and any other programs (not shown)executing on computer 120. Since microcode 130 is a component of CPU306, the use of microcode 130 to contain program 100, is typical of a“hardware” embodiment of the present invention. Such a hardwareembodiment is inherently faster and therefore preferred over a softwareembodiment. The hardware embodiment is also preferred because operatingsystem 304 and other software may be changed at will without loss ofattack inhibition.

[0048] Computer program 100 together with certain elements of hardwaretogether form a “processor” 302 as depicted in FIG. 3. It will beappreciated that the terms “processor,” “‘macro’ processor,” and“‘micro’ processor,” as discussed herein, are limited to the definitionsdescribed herein, and that no other definitions are intended or implied.

[0049] When the present invention is realized in a software embodiment,as discussed hereinbefore, processor 302 is a “macro” processor 308formed of operating system 304, CPU 306, and memory 128. Operatingsystem 304 contains program 100. CPU 306 reads and carries out theinstructions of operating system 128. Memory 128 is associated withoperating system 304 and CPU 306 and contains pointers (addresses) to beencrypted and decrypted, and may also contain keys and other protecteddata (discussed hereinafter). It is understood that operating system 304itself resides in memory 128. An additional component of “macro”processor 308 is compiler 310 used to compile operating system 304.

[0050] Conversely, when the present invention is realized in a hardwareembodiment, as discussed hereinbefore, processor 302 is a “micro”processor 312 formed of CPU 306 and memory 128. Within CPU 306 thereexists microcode 130, registers 314, and logic elements 316. Microcode130 contains program 100. Logic elements 316 read and carry out theinstructions of microcode 130. Memory 128 is associated with operatingsystem 304 and microcode 130 and contains pointers (addresses) to beencrypted and decrypted. Registers 314 contain keys and other protecteddata (discussed hereinafter). While not explicitly depicted in FIG. 3,compiler 310 may be used to compile microcode 304.

[0051] It may also be desirable to realize a software embodiment of thepresent invention in which operating system 128 contains program 100,memory 128 contains pointers (addresses) to be encrypted and decrypted,and registers 314 contain keys and other protected data (discussedhereinafter).

[0052] Those skilled in the art will appreciate that the software andhardware embodiments discussed hereinbefore are exemplary only, and thatother embodiments are realizable. For example, a composite embodimentmay be realized in which a hardware embodiment uses oneencryption/decryption algorithm and a software embodiment uses anotherencryption/decryption algorithm. By proper selection of the algorithms,a system may be realized which has a lower level general protection athigh speed (the hardware embodiment) and a higher level specificprotection at a slower speed (the software embodiment). The use of theseand other embodiments does not depart from the spirit of the presentinvention.

[0053] Those skilled in the art will also appreciate that program 100remains configured to inhibit buffer-overflow and otherpointer-overwrite attacks whether program 100 is dormant or active.Throughout the remainder of this discussion, program 100 is assumed tobe active.

[0054] Referring to FIGS. 1, 2, and 3, a phantom configuration decision202 is made to distinguish between hardware and software embodiments ofthe present invention. If a hardware embodiment, then in a task 204computer program 100 is incorporated into CPU microcode 130 andattack-inhibiting procedure 200 is executed therefrom. Conversely, if asoftware embodiment, then in a task 206 computer program 100 isincorporated into operating system 304 in system memory 128 andprocedure 200 is executed therefrom.

[0055] All sub-procedures and tasks in attack-inhibiting procedure 200discussed hereinafter are presumed to be effected in either CPUmicrocode 130 or operating system 304 as determined by decision 202. Tosimplify this discussion, the present invention is presumed throughoutthe remainder of this discussion to be realized in a software embodimentwith program 100 contained within operating system 304, residing withinmemory 128, and effecting attack-inhibiting procedure 200, except wherespecifically indicated otherwise.

[0056] As demonstrated in FIG. 1, computer program 100 contains aplurality of code portions 102. Each code portion 102 is configured toeffect a specific task within attack-inhibiting procedure 200. Thisbeing the case, discussion of a given task will be assumed to bediscussion of the specific code portion 102 within program 100configured to effect that task. A reference number assigned to a giventask therefore references both the task and its specific code portion.

[0057]FIG. 4 shows a flowchart of a key-generation procedure 210 as asub-procedure of attack-inhibiting procedure 200, and FIG. 5 shows abit-width comparison between addresses and values used in computerprogram 100 in accordance with a preferred embodiment of the presentinvention. The following discussion refers to FIGS. 2, 4, and 5.

[0058] Program 100 effects key-generation procedure 210 ofattack-inhibiting procedure 200. Within key-generation procedure 210, atask 402 generates an encryption key 502 and a task 404 generates adecryption key 504. Keys 502 and 504 are used to encrypt and decryptprocess addresses 104 as discussed hereinafter.

[0059] Those skilled in the art will appreciate that tasks 402 and 404may be combined into a single task 402 that generates a single key 502for both encryption and decryption of process addresses 104. For thesake of simplicity, this discussion assumes the use of separateencryption and decryption keys 502 and 504. It should be understood,however, that the use of one key 502 for both encryption and decryptiondoes not depart from the spirit of the present invention.

[0060] Keys 502 and 504 are desirably protected. If an attacker were togain access to (i.e., read the value of) keys 502 and 504, then thatattacker might be in a position to subvert the encryption and decryptionmethodology and implant and execute malicious code.

[0061] Once tasks 402 and 404 have generated keys 502 and 504, a phantomquery task 406 distinguishes between hardware and software embodimentsof the present invention. If the present invention is embodied inhardware, then a task 408 contains (i.e., stores) keys 502 and 504 inregisters 314 within CPU 306. Since this is a hardware embodiment, whichrequires configuration of CPU 306 during manufacture, these registers314 may be dedicated “key registers.” This allows keys 502 and 504 to becontained without sacrificing functionality and performance of CPU 306.

[0062] If the present invention is embodied in software, then a querytask 410 determines if registers 314 are available for keys 502 and 504.If task 410 determines that registers 314 are available, then task 408contains keys 502 and 504 in those registers 314. Since this is asoftware embodiment, these registers 314 are typically not dedicated“key registers” and are usurped for this purpose. This means that CPU306 may lose these registers 314, with a possible subsequent decrease infunctionality and performance.

[0063] If task 410 determines that registers 314 are not available, thena task 412 contains keys 502 and 504 in memory 128. Since it isdesirable that keys 502 and 504 be protected, keys 502 and 504 aretypically stored in read-only memory. For example, in Unix and Unix-likesystems, keys 502 and 504 would be stored in either the text or rodatasegment, rather than in either the data or bss segment.

[0064] Tasks 406 and 410 may be implicit tasks. That is, tasks 406 and410 may reside within decision 202 and not be explicitly implemented. Insuch a case only the desired one of tasks 408 and 412 need beincorporated within attack-inhibiting procedure 200.

[0065] Keys 502 and 504 are desirably generated during operating systeminitialization and as a part of the initialization of each process(program) executed on computer 120. It is often desirable to generatekeys 502 and 504 anew at intervals during operation of computer 120.Such repeated generation of keys 502 and 504 significantly increases thelevel of security of the system. The interval may be periodic orirregular, as desired, with a random and more frequent key intervaloffering the greatest increase in security.

[0066] When repeated generation is desired, an optional query task 414is used to determine when the interval (not shown) has passed. When theinterval has passed, procedure 210 is repeated and keys 502 and 504 areagain generated and contained. Task 414 remains active in the backgroundto cause generation after each interval.

[0067] Keys 502 and 504 are desirably generated using random-seedtechniques well known in the art. This results in different keys 502 and504 after each generation. Those skilled in-the art will appreciate thatdata encryption must therefore take place after each generation of keys502 and 504 to avoid decryption failure.

[0068] Referring to FIG. 5, process addresses 104 (i.e., addresses ofand/or associated with a process or operation within operating system304) have a predetermined number of bits 506, i.e., have a predeterminedbit length 508. Bit length 508 is a property of CPU 306 and memory 128.As depicted, bit length 508 is thirty-two bits 506. It will beappreciated, however, that this is purely exemplary. Other bit lengths508 may be used for process addresses 104 without departing from thespirit of the present invention.

[0069] Desirably, keys 502 and 504 have at least as many bits 506 asprocess address 104, i.e., have a bit length 510 at least as great asprocess-address bit length 508. More desirably, keys 502 and 504 have abit length 510 of at least sixty-four bits 506. This provides keys 502and 504 that have a very low probability of determination. That is, anattack would find it nearly impossible to guess the values of keys 502and 504.

[0070]FIG. 6 shows a flowchart of an address-encryption procedure 220 asa sub-procedure of attack-inhibiting procedure 200 in accordance with apreferred embodiment of the present invention. The following discussionrefers to FIGS. 2, 5, and 6.

[0071] Following key generation, program 100 effects address-encryptionprocedure 220 of attack-inhibiting procedure 200. In conventional (i.e.,non-encrypted) systems, process address 104 is produced and placed intodata memory 128, e.g., a return address is determined and PUSHed ontothe stack. In procedure 220, process address 104 is encrypted beforebeing placed into data memory 128.

[0072] As depicted in FIG. 6, procedure 220 is effected for each process(not shown) in operating system 304 containing a process address 104stored in read/write memory 128. Since in many operating systems 304,virtually all processes are CALLed, i.e., accessed though a CALLfunction. CALLed processes have a return address PUSHed onto the stack,i.e., written to writeable memory 128. The return address of each CALLedprocess is therefore an exposed process address 104 and should beencrypted. This encryption should desirably take place interactively,i.e., when the process is CALLed. Also, the CALL address of a process,i.e., the actual address 104 of a process where it resides in memory128, is often located in read-only portions of memory 128. This address104 is still vulnerable to inspection and capture, and should beencrypted. This encryption should desirably take place during systeminitialization and each type encryption key 502 is updated. Therefore,it is desirable that all process addresses 104 in operating system 304be encrypted.

[0073] Within address-encryption procedure 220, an optional task 602generates a nonce value 512. Nonce value 512 is an arbitrary and randomvalue used to deepen the encryption of a process address 104 asdiscussed hereinafter.

[0074] Since nonce value 512 is a part of the encryption process, noncevalue 512 is desirably protected. If an attacker were to gain access tononce value 512, then that attacker would be more able to subvert theencryption and decryption methodology and implant and execute maliciouscode.

[0075] Once task 602 has generated nonce value 512, a phantom query task604 distinguishes between hardware and software embodiments of presentinvention. If the present invention is embodied in hardware, then a task606 contains (i.e., stores) nonce value 512 in a register 314 within CPU306. Since this is a hardware embodiment, which requires modification ofCPU 306 during manufacture, each of these registers 314 may be adedicated “nonce register.” This allows each nonce value 512 to becontained without sacrificing functionality and performance of CPU 306.

[0076] If the present invention is embodied in software, then a querytask 608 determines if a register 314 is available for nonce value 512.If task 608 determines that a register 314 is available, then task 606contains nonce value 512 in that register 314. Since this is a softwareembodiment, these registers 314 are typically not dedicated “nonceregisters” and are usurped for this purpose.

[0077] If task 608 determines that a register 314 is not available, thena task 610 contains nonce value 512 in memory 128. Since it is desirablethat nonce value 512 be protected, nonce value 512 is typically storedin read-only memory.

[0078] Tasks 604 and 608 may be implicit tasks. That is, tasks 604 and608 may reside within decision 202 and not be explicitly implemented. Insuch a case only the desired one of tasks 606 and 610 need beincorporated within attack-inhibiting procedure 200.

[0079] Desirably, a different nonce value 512 is used for each processin operating system 304. Operating system 304 may contain hundreds oreven thousands of processes. This may make it impossible to obtainsufficient registers 314. Under these circumstances, tasks 608 and 606are not feasible and are omitted, and task 610 contains nonce value 512in memory 128 if a software embodiment is effected.

[0080] Desirably, nonce values 512 are generated for each process whenstarted by the operating system. In some implementations, this may notbe possible. Under these conditions, it may be necessary to generatefewer nonce values 512 than there are processes. That is, processes maybe made to share nonce values 512.

[0081] In an alternative embodiment, it may be desirable to generatekeys 502 and 504 in response to a nonce value 512. Those skilled in theart will appreciate that this may be accomplished by migrating tasks602, 604, 606, 608, and 610 into procedure 210. The use of this or otheralternative embodiments does not depart from the spirit of the presentinvention.

[0082] While not specifically depicted in FIG. 6, those skilled in theart will appreciate that it may be desirable in some embodiments togenerate nonce values 512 anew at intervals during operation of computer120. Such repeated generation of nonce values 512 may increase the levelof security of the system. The interval may be periodic or irregular, asdesired, with a random key interval offering the greatest increase insecurity.

[0083] When repeated generation of nonce values 512 is desired, it maybe accomplished in a manner analogous to the repeated generation of keys502 and 504 discussed hereinbefore.

[0084] Nonce values 512 are desirably generated using random-seedtechniques well known in the art. This results in different values foreach nonce value 512 generated.

[0085] Referring to FIG. 5, nonce values 512 desirably have a bit length514 of at least twenty-four bits, and more desirably have a bit length514 equal to process-address bit length 508. This provides nonce values512 that have a very low probability of determination. That is, anattack would find it nearly impossible to determine the values of noncevalues 512.

[0086] Those skilled in the art will appreciate that the use of noncevalues 512 is optional. When it is desired to forego the use of noncevalues 512, tasks 602, 604, 606, 608, and 610 are omitted.

[0087] Procedure 220 then executes a task 612 to produce process address104. Task 612 effectively “captures” or intercepts process address 104generated or retrieved by operating system 304.

[0088] As discussed hereinbefore, process address 104 is a pointerstored in memory 128 which is to be loaded into a program counter 318within CPU 306. Process address 104, therefore, may be an address in aread-only segment of memory 128 where a process resides (i.e., aconstant-function pointer), an address in a read/write segment of memory128 (e.g., in the stack) to which control will jump or return uponcompletion of a process (i.e., a call-and-return pointer), an address ina table to which control will be transferred (i.e., a transfer pointer),or an address which points to another address (i.e., a secondarypointer).

[0089] When nonce values 512 are used, a task 614 then combines processaddress 314 with an appropriate nonce value 512 to produce anaddress/nonce value 516. Task 614 may combine process address 104 andnonce value 512 in any of numerous ways well known to those skilled inthe art. Each of these ways has advantages and disadvantages and may beused without departing from the spirit of the present invention. Typicalof such ways are adding, XORing, and concatenating. For address/noncevalue 516, task 614 has concatenated process address 104 and nonce value512.

[0090] A task 616 then encrypts address/nonce value 516 (if nonce values512 are used) or process address 104 (if nonce values 512 are not used)in response to encryption key 502 to produce an encrypted address 518.

[0091] Desirably, task 616 performs this encryption using the AdvancedEncryption Standard algorithm from the National Institute of Standardsand Technology. Those skilled in the art will appreciate, however, thatthis is not a requirement of the present invention, and that otherencryption algorithms may be used without departing from the spirit ofthe present invention. For example, the encryption process may includethe storage address in memory 128 as a part of the data encrypted or ofthe key value used. This or any of numerous other methods of inputtingthe storage address into the encryption process may be used.

[0092] Task 616 for a given process is performed each time an encryptionkey 502 for that process is generated, i.e., during process startup orsystem initialization and after each key interval. In some alternativeembodiments, it may be desirable to link the key interval to processusage. In such an embodiment, a new encryption key 502 may be generatedand task 616 executed each time the process is used.

[0093] Desirably, a task 618 then stores encrypted address 518 in memory128 in lieu of process address 104. Since encrypted address 518 is to bestored in memory 128 in lieu of process address 104, it is desirablethat encrypted address 518 has a bit length 520 that is substantiallythe same as process-address bit length 508. This allows encryptedaddress 518 to dovetail into operating system 304 and other areas ofmemory 128 without further modification.

[0094] Following task 618, address-encryption procedure 220 ends, andprogram control then proceeds within operating system 304.

[0095]FIG. 7 shows a flowchart of an address-decryption procedure as asubprocess of attack-inhibition procedure 200 in accordance with apreferred embodiment of the present invention. The following discussionrefers to FIGS. 2, 5, and 7.

[0096] Program 100 then effects address-decryption procedure 230 as asub-procedure of attack-inhibiting procedure 200. In conventional (i.e.,non-encrypted) systems, process address 104 is retrieved from memory 128and placed into program counter 318, e.g., a return address is POPedfrom the stack and loaded into program counter 318. In procedure 230,process address 104 is decrypted before being placed into programcounter 318.

[0097] Within address-decryption procedure 230, a task 702 retrievesencrypted address 518 from memory 128. A task 704 then decryptsencrypted address 518 in response to decryption key 504 (for a dual-keyembodiment) or key 502 (for a single-key embodiment). The method used bytask 704 to decrypt encrypted address 518 is the compliment of themethod used by task 616 (discussed hereinbefore) to produce encryptedaddress 518. If nonce values 512 are not used, task 704 reproducesprocess address 104.

[0098] If nonce values 512 are used, task 704 reproduces address/noncevalue 516. A task 706 then extracts process address 104 and nonce value512 from address/nonce value 516. The method used by task 706 to extractprocess address 104 and nonce value 512 is dependent upon the methodused by task 614 (discussed hereinbefore) to produce address/nonce value516. For address/nonce value 516, task 614 has concatenated processaddress 104 and nonce value 512. Therefore, task 706 dividesaddress/nonce value 516 to reproduce process address 104 and nonce value512.

[0099] Following task 706 (if nonce values 512 are used) or task 704 (ifnonce values 512 are not used), a task 708 may be used to determine ifprocess address 104 is valid. In most modern operating systems 304, alarge part of CPU 306 address space will be empty. Therefore, only afraction of randomly chosen values for program counter 318 will belegitimate process addresses 104, i.e., will point to a valid areawithin memory 128. Operating system 304 itself is typically configuredso that an illegitimate process address 104 will cause an immediatefault. Also, for some CPUs 306, values for program counter 318 must havespecific alignments, e.g., sixteen or thirty-two bit boundaries. CPU 306may cause an immediately fault if the value of program counter 318 isnot properly aligned. Task 708 desirably checks process address 104these and other address features which may signal address invalidity.

[0100] A fault caused by an illegitimate value in program counter 318may itself be unpredictable. That is, there may be no practical way ofdetermining where operation will go and what will occur when it getsthere. Task 708 eliminates this problem by determining if processaddress 104 is valid before process address 104 is placed into programcounter 318. Task 708 may accomplish this by comparing process address104 against acceptable values for program counter 318.

[0101] Those skilled in the art will appreciate that task 708 isoptional. If task 708 is not used, then an illegal value for processaddress 104 may result in an uncontrolled system crash unless noncevalue 512 is used and verified. Nevertheless, a system crash is deemedpreferable to the execution of malicious code.

[0102] If nonce value 512 is used, and if task 708 is not used or isused and determines that process address 104 is valid, a task 710 may beused to determine if nonce value 512 is valid. If an attack has occurredcorrupting a given encrypted address 518, then nonce value 512 extractedfrom that corrupted encrypted address 518 will not match the originalnonce value 512 generated by task 602 (discussed hereinbefore). Task 710determines if nonce value 512 is valid before process address 104 isplaced into program counter 318.

[0103] If task 708 determines that process address 104 is valid and task710 is not used, or task 708 is not used and task 710 determines thatnonce value 512 is valid, or task 708 determines that process address104 is valid and task 710 determines that nonce value 512 is valid, thena task 712 places process address 104 in program counter 318 and controlis transferred to a valid process 106 whose starting location in memory128 is process address 104, as indicated at a task 714.

[0104] Conversely, if either task 708 determines that process address104 is invalid or task 710 determines that nonce value 512 is invalid,then a task 716 places a crash address 108 in program counter 318 andcontrol is transferred to a crash and terminate process 110 as indicatedat a task 718. Crash and terminate process 110 is a process that allowsa “controlled crash” of computer 120 or the affected process. That is,crash and terminate process 110 desirably performs safe shutdownprocedures, displays a message notifying an operator of the systemcrash, and terminates the operation of computer 120. This action isbased upon the assumption that it is better to terminate operation thanto allow the system to be compromised.

[0105] Those skilled in the art will appreciate that task 616 and crashand terminate process 110 are not requirements of the present inventionand may be omitted without departing from the spirit of the presentinvention.

[0106] Those skilled in the art will also appreciate that othercorrective actions may be taken in lieu of task 616 and crash andterminate process 110 without departing from the spirit of the presentinvention. For example, in a Unix process, the damaged process mightreceive a signal and execute a “longjmp( )” call to return to the mainloop of the program and possibly re-initialize the process. Such“exception-handling” processes are well known in the art.

[0107] By encrypting process addresses 104 that are stored in writeablesegments of memory 128, or, more desirably, all process addresses 104,the present invention inhibits buffer-overflow and memory-manipulationattacks. If all process addresses 104 are encrypted while stored inwriteable memory 128, an attacker may still be able to gain access toand successfully modify a given process address 104. However theattacker will be unable to predict where the modified address willactually point after decryption.

[0108] Thus, if process addresses 104 are encrypted, the most probableeffect of a successful buffer overflow attack would be to cause animmediate fatal error in the corrupted process, rather than execute theattacker's code. Desirably, the attack will result in execution of crashand terminate process 110 and results in a denial of service to computer120. The attack does not result in an undetected compromise of theattacked system. This is a major improvement over prior-art techniques.

[0109] As discussed hereinbefore, encryption and decryption procedures220 and 230 would ideally reside in microcode 130 within CPU 306 itself,or directly in hardware logic in a state machine (e.g., a RISC-typeCPU). This would allow decryption procedure 230 to be performedautomatically as part of the microcode instruction loading programcounter 318. In this “hardware” embodiment, the encryption anddecryption keys 502 and 504 may be held in processor registers 314,inaccessible to the actual processes (i.e., the operating system andother higher-level programs).

[0110] The present invention therefore implements an alternativeencrypted process address 104 strategy using a “software” embodiment. Inthis alternative strategy a compiler 310 is modified to produce anoperating system 304 containing the elements of computer program 100.

[0111]FIG. 8 shows a flowchart of a compilation procedure 800 forcreation of attack-inhibiting procedure 200 in accordance with apreferred embodiment of the present invention. The following discussionrefers to FIG. 8.

[0112] Through compilation procedure 800, compiler 310 compiles computerprogram 100 to include code to perform encryption and decryption ofprocess addresses 104 that may be loaded into program counter 318.

[0113] It may be desirable to extend the bit length of function pointers(i.e., of process addresses 104) to reduce the probability that a randomaddress value from an attacker might succeed (e.g., in a “birthday”attack). Within procedure 800, a query task 802 determines if the bitlength 508 of process addresses 104 is to be extended. If task 802determines that bit length 508 is to be extended, then a task 804compiles code to extend bit length 508 of each process address 104 inprogram 100.

[0114] Those skilled in the art will appreciate that tasks 802 and 804are optional, i.e., are not a requirement of the present invention. Theomission of tasks 802 and 804 does not depart from the spirit of thepresent invention.

[0115] Additionally, those skilled in the art will appreciate that, whentask 804 is used, task 802 may be implicit. The use of an implicit task802 does not depart from the spirit of the present invention.

[0116] A task 806 then compiles code to incorporate per-process noncevalues 512 into each process address 104. These nonce values 512 may bechecked after decryption as an additional defense and attack-detectionmechanism as discussed hereinbefore in connection with tasks 710, 716,and 718.

[0117] Those skilled in the art will appreciate that task 806 is alsooptional, and that omission of task 806 does not depart from the spiritof the present invention.

[0118] As discussed hereinbefore, process address 104 is a pointerstored in memory 128, which is to be loaded into a program counter 318within CPU 306. Process address 104, therefore, may be aconstant-function pointer 104 (i.e., an address in a read-only segmentof memory 128 where a process resides), a call-and-return pointer 104(i.e., an address in a read/write segment of memory 128 (e.g., in thestack) to which control will jump or return upon completion of aprocess), a transfer pointer 104 (i.e., an address in a table to whichcontrol will be transferred), or a secondary pointer 104 (i.e., anaddress which points to another address). Each of these pointer types ishandled separately.

[0119] A task 808 compiles code to encrypt and decrypt constant-functionpointers 104, a task 810 compiles code to encrypt and decryptcall-and-return pointers 104, a task 812 compiles code to encrypt anddecrypt transfer pointers 104, and a task 814 compiles code to encryptand decrypt secondary pointers 104.

[0120] Those skilled in the art will appreciate that the code compiledby tasks 808, 810, 812, and 814 encrypt and decrypt process addresses104 during initialization (boot) and operation of computer 120.

[0121] In summary, the present invention teaches a procedure 200 andprogram 100 for inhibiting attack upon a computer 120. Process addresses104 are encrypted, stored, and decrypted prior to being placed in aprogram counter 318. The encryption and decryption of process addresses104 may be effected within a CPU 306, may be effected through the use ofsecure keys 502 and 504, and may be effected in conjunction with a noncevalue 512. Post-decryption verification of process addresses 104 issupported.

[0122] Although a preferred embodiment of the invention has beenillustrated and described in detail, it will be readily apparent tothose skilled in the art that various modifications may be made thereinwithout departing from the spirit of the invention or from the scope ofthe appended claims.

What is claimed is:
 1. A method for inhibiting attack upon a computer,said method comprising: producing a process address to be used by aprogram counter of said computer; encrypting said process address toproduce an encrypted address; storing said encrypted address in a memoryof said computer; retrieving said encrypted address from said memory;and decrypting said encrypted address to reproduce said process address.2. A method as claimed in claim 1 wherein said encrypting and decryptingactivities are effected within an operating system of said computer. 3.A method as claimed in claim 1 additionally comprising generating a keyfor one of said encrypting and decrypting activities.
 4. A method asclaimed in claim 3 additionally comprising containing said key within anoperating system of said computer.
 5. A method as claimed in claim 3additionally comprising containing said key within a register of acentral processing unit of said computer.
 6. A method as claimed inclaim 3 wherein: said process address is expressed in a predeterminednumber of bits; and said key contains at least as many bits as saidprocess address.
 7. A method as claimed in claim 3 wherein said keycontains at least sixty-four bits.
 8. A method as claimed in claim 3wherein said generating activity generates said key at each boot of saidcomputer.
 9. A method as claimed in claim 3 wherein said generatingactivity generates said key at startup of a process in said computer.10. A method as claimed in claim 3 wherein said generating activitygenerates said key at intervals during operation of said computer.
 11. Amethod as claimed in claim 1 additionally comprising: generating anencryption key for said encrypting activity; and generating a decryptionkey for said decrypting activity.
 12. A method as claimed in claim 1additionally comprising: generating a nonce value; and generating a keyfor one of said encrypting and decrypting activities in response to saidnonce value.
 13. A method as claimed in claim 1 wherein: said methodadditionally comprises generating a nonce value; said encryptingactivity encrypts said process address in conjunction with said noncevalue to produce said encrypted address; said decrypting activitydecrypts said encrypted address to reproduce said process address andsaid nonce value; said method additionally comprises, after saiddecrypting activity, determining if said nonce value is valid; and saidmethod additionally comprises placing said process address in saidprogram counter when said determining activity determines said noncevalue is valid.
 14. A method as claimed in claim 13 additionallycomprising placing a crash address in said program counter when saiddetermining activity determines said nonce value is invalid.
 15. Amethod as claimed in claim 1 wherein: said method additionally comprisesgenerating a nonce value prior to said encrypting activity; saidencrypting activity comprises: combining said process address and saidnonce value to produce an address/nonce value; and encrypting saidaddress/nonce value to produce said encrypted address; and saiddecrypting activity comprises: decrypting said encrypted address toreproduce said address/nonce value; and extracting said process addressand said nonce value from said address/nonce value.
 16. A method asclaimed in claim 1 wherein said encrypting activity encrypts saidprocess address utilizing the Advanced Encryption Standard.
 17. A methodas claimed in claim 1 additionally comprising configuring an operatingsystem of said computer to effect said encrypting and decryptingactivities.
 18. A method as claimed in claim 1 additionally comprising:determining, after said decrypting activity, if said process address isvalid; and placing said process address in said program counter whensaid determining activity determines said process address is valid. 19.A method as claimed in claim 18 additionally comprising placing a crashaddress in said program counter when said determining activitydetermines said process address is invalid.
 20. A method as claimed inclaim 18 wherein said determining activity compares said process addressagainst valid return address values for said program counter.
 21. Aprocessor configured to inhibit attack, said processor comprising: amemory; a first code portion that encrypts a process address to producean encrypted address and stores said encrypted address in said memory;and a second code portion that retrieves said encrypted address fromsaid memory and decrypts said encrypted address to reproduce saidprocess address.
 22. A processor as claimed in claim 21 additionallycomprising a register configured to contain a key, wherein said firstcode portion encrypts said process address in response to said key, andsaid second code portion decrypts said encrypted address in response tosaid key.
 23. A processor as claimed in claim 22 wherein said keycontains at least as many bits as said process address.
 24. A processoras claimed in claim 21 additionally comprising: a first registerconfigured to contain a first key, wherein said first code portionencrypts said process address in response to said first key; and asecond register configured to contain a second key, wherein said secondcode portion decrypts said encrypted address in response to said secondkey.
 25. A processor as claimed in claim 21 wherein: said first codeportion produces an address/nonce value from said process address and anonce value; said first code portion encrypts said address/nonce valueto produce said encrypted address; said second code portion decryptssaid encrypted address to reproduce said address/nonce value; and saidsecond code portion reproduces said process address and said nonce valuefrom said address/nonce value.
 26. A processor as claimed in claim 25wherein: said processor additionally comprises a program counterconfigured to receive said process address and to route control to saidprocess address; said second code portion verifies validity of saidnonce value; and said second code portion places said process addressinto said program counter when said nonce value is valid.
 27. Aprocessor as claimed in claim 26 wherein said second code portion placesa crash address into said program counter when said nonce value isinvalid.
 28. A computer program configured to operate upon a computerand to inhibit attack upon said computer, wherein said computer programresides upon a computer-readable medium, and wherein said computerprogram comprises: a first code portion configured to encrypt a processaddress to produce an encrypted address; a second code portionconfigured to store said encrypted address in a memory of said computer;a third code portion configured to retrieve said encrypted address fromsaid memory; a fourth code portion configured to decrypt said encryptedaddress to reproduce said process address; and a fifth code portionconfigured to place said process address in a program counter of saidcomputer.
 29. A computer program as claimed in claim 28 wherein: saidcomputer program additionally comprises a sixth code portion configuredto produce a nonce value; said first code portion is configured toencrypt said process address and said nonce value to produce saidencrypted address; and said fourth code portion is configured to decryptsaid encrypted address to reproduce said process address and said noncevalue.
 30. A computer program as claimed in claim 29 wherein: saidcomputer program additionally comprises a seventh code portionconfigured to verify validity of said nonce value; and said fifth codeportion is configured to place said process address in said programcounter when said nonce value is valid.
 31. A computer program asclaimed in claim 30 wherein said computer program additionally comprisesan eighth code portion configured to place a crash address into saidprogram counter when said nonce value is invalid.
 32. A computer programas claimed in claim 28 additionally comprising a sixth code portionconfigured to generate a key, wherein one of said first code portion isconfigured to encrypt said process address and said fourth code portionis configured to decrypt said encrypted address in response to said key.33. A computer program residing upon a computer-readable medium andconfigured to inhibit attack upon a computer, said computer programcomprising: a first code portion which produces a process address for aprogram counter of said computer; a second code portion which encryptssaid process address and produces an encrypted address therefrom; athird code portion which stores said encrypted address in a memory ofsaid computer; a fourth code portion which retrieves said encryptedaddress from said memory; a fifth code portion which decrypts saidencrypted address to reproduce said process address; and a sixth codeportion which places said process address in said program counter.
 34. Acomputer program as claimed in claim 33 wherein: said computer programadditionally comprises a seventh code portion which determines if saidprocess address decrypted by said fifth code portion is valid; and saidsixth code portion places said process address in said program counterwhen said seventh code portion determines said process address is valid.35. A computer program as claimed in claim 34 additionally comprising aneighth code portion which places a crash address in said program counterwhen said seventh code portion determines said process address isinvalid.
 36. A computer program as claimed in claim 33 additionallycomprising a seventh code portion which generates a nonce value.
 37. Acomputer program as claimed in claim 36 wherein: said computer programadditionally comprises an eighth code portion which combines saidprocess address and said nonce value to produce an address/nonce value;said second code portion encrypts said address/nonce value to producesaid encrypted address; said fifth code portion decrypts said encryptedaddress to reproduce said address/nonce value; said computer programadditionally comprises a ninth code portion which extracts said processaddress and said nonce value from said address/nonce value; and saidcomputer program additionally comprises a tenth code portion whichdetermines if said nonce value is valid.
 38. A computer program asclaimed in claim 37 wherein said sixth code portion places said processaddress in said program counter when said tenth code portion determinessaid nonce value is valid.
 39. A computer program as claimed in claim 37additionally comprising an eleventh code portion which places a crashaddress in said program counter when said tenth code portion determinessaid nonce value is invalid.
 40. A computer program as claimed in claim33 additionally comprising a seventh code portion which generates a key.41. A computer program as claimed in claim 40 wherein said second codeportion encrypts said process address in response to said key.
 42. Acomputer program as claimed in claim 40 wherein said fifth code portiondecrypts said encrypted address in response to said key.
 43. A method ofcompiling a computer program residing upon a computer-readable mediumand configured to inhibit attack upon a computer, said methodcomprising: compiling code to encrypt and decrypt constant-functionpointers during operation of said computer program; and compiling codeto encrypt and decrypt call-and-return pointers during operation of saidcomputer program.
 44. A method as claimed in claim 43 additionallycomprising compiling code to encrypt and decrypt said constant-functionpointers during initialization of said computer program.
 45. A method asclaimed in claim 43 additionally comprising: determining a bit length ofsaid of said constant-function pointers; and extending said bit length.46. A method as claimed in claim 43 additionally comprisingincorporating a per-process nonce value into said constant-functionpointers.
 47. A method as claimed in claim 43 additionally comprisingcompiling code to encrypt and decrypt secondary pointers of saidcomputer program, wherein each of said secondary pointers points to oneof said constant-function pointers.
 48. A method as claimed in claim 43additionally comprising compiling code to encrypt and decrypt transferpointers during operation of said computer program.